Curse

Gill Halendt · Jun 17, 2010, 01:09 PM // 13:09

Quote:

Originally Posted by Amy Awien

If the negative effect of syncing exceeds that of an occasional long wait then the choice for the longer wait would be reasonable.

That's the core problem: it depends on Anet and their perception of the syncing issue. Right now, they seem to be reasonably satisfied with the current solution, so it's not really a problem in their books. We could discuss about possible solutions for weeks, the (perceived) modest impact of syncing on the game right now prevents any significant intervention from Anet. They're not investing significant resources on something they deem as a non-issue. Sad, but true.

Quote:

Originally Posted by Amy Awien

If you have as many arena's as needed to empty the queue then implementing randomization of assignment to teams while maintaining a FIFO is not so hard - and it would have negligable impact on performance.

Introducing randomization would make such a queue not FIFO anymore. That implies that most of the algorithm and data structures must be rewritten, pretty much from scratch. Is it worth it?

Any player would likely say it is. What about Anet? See above.

Amy Awien · Jun 17, 2010, 01:37 PM // 13:37

Quote:

Originally Posted by Gill Halendt

Introducing randomization would make such a queue not FIFO anymore. That implies that most of the algorithm and data structures must be rewritten, pretty much from scratch. Is it worth it?

Could pop them from the queue in FIFO order and then pick a random team for each. That way you'd break any attempts by players to sync, or create their own order.

int rnd;
while(!waitqueue.isempty()){
player = waitqueue.dequeue();
do {
rnd = random(teams.count());
} while (teams[rnd].isfull())
teams[rnd].add(player);
}

You probably don't need any extra structures, just have to know how many teams you can make

Martin Alvito · Jun 17, 2010, 02:52 PM // 14:52

Quote:

Originally Posted by Amy Awien

No, no, no, you were being nasty, if you'd truly believed I didn't know the word you'd have used half a sentence to explain it.

This is the Internet. One tries to avoid using many words when few will do, especially since there are such excellent resources out there enabling you to resolve the issue yourself.

Quote:

Originally Posted by Amy Awien

No, you ignore the point when you start to argue about 'average' waiting time, where the point is that an extremely long waiting time will have a more impact on perception then the 'average' time. You then claim, without any evidence, that the chance of (extremely) long waiting times is negligible.

If it's the case that the variance increases but the mean doesn't move much on a skewed distribution like this, then it follows that the chance of experiencing the result out in the tail, many timers in succession, is very small.

You continue to insist that I lack evidence, but we don't need to induct from empirical evidence to solve this problem. We can use logic and a bit of math and deduct the odds of failing to match. You are essentially insisting that we have to do things Darwin's way, but Newton's mechanics and Einstein's relativity are also useful theories, no?

The following is a rigorous proof of my claims:

Start by defining two natural numbers: N and q.

Let's assume that ANet's coders are smart, and that the pairing system always matches every player possible. If that's the case, then every 30 seconds the game creates N games with 8N players in them, and from 0 to 7 players are left out in the cold. (This assumes away the problem of leavers; doing so reduces the hypothetical number of players and improves the result for your side.) Assume that the number of players that does not match is truly random, yielding an equivalent probability of 1/8 for each case. (This should be a truly random process).

If the above is true, then if we implement Lemming's proposal, your odds of drawing a single NOP are given by 1/(8N+3.5), and the odds of drawing q NOPs in sequence are given by 1/(8N+3.5)^q. However, your risk for drawing a single NOP has not changed from the status quo (since you don't know where the timer stands when you click it), so all we are really concerned about is the cases where q>1.

We'll make a final assumption that is extremely charitable to your side. Since we almost never experience an NOP, much less multiple NOPs at present, we can infer that N>0 almost all of the time. The worst case scenario would therefore be N=1.

Given N=1, it follows that the odds of drawing two NOPs are 1/(11.5)^2, the odds of three are 1/(11.5)^3 and so forth. If you run the math, all this really does is increase the chances of a negative result by an order of magnitude as compared to the original math I provided. Your odds of experiencing four NOPs, even given these very charitable assumptions, are therefore worse than your odds of winning a four ball daily lottery in a Northeastern state. Moreover, the average number of additional timers you wait under Lemming's proposal are, as advertised, just under 0.1 when you solve the infinite series with N=1.

So there you have it: rigorous deductive proof of everything I have claimed. Empirical evidence is irrelevant here; all it will do is confirm the assumptions and fill in the proper value of N, which is probably > 1. Increases in the value of N will decrease the risks of long timers very rapidly, since the denominator is exponential.

Conclusion: the risks of long waits under Lemming's proposal are minimal.

Gill Halendt · Jun 17, 2010, 03:10 PM // 15:10

Quote:

Originally Posted by Martin Alvito

If that's the case, then every 30 seconds the game creates N games with 8N players in them

We don't know this for sure though.

As far as we know, there might be limitations to the number of games created per session. Entirely possible, since servers capacity is not infinite, so assuming that the number of games created is always N of players / 8 is potentially wrong or inaccurate.

Right now, processing the queue in order prevents problems with such a limit. You click a button, you're high in the queue, you get in, people clicking after you are lower in the queue and might get in later. As soon as there are enough players in the queue to form a minimum ammount of teams to start the game, the set timer ends and the game starts.

Randomization means you have no regular flow of players out of the queue, so the extreme cases are people coming late and getting in in a matter of seconds, and people waiting for multiple timers to deplete, maybe even surpassed in the queue by players who have played a full match already and got back.

The average waiting times are likely similar, but each player's experience could be extremely variable. Not a behaviour I'd like in my system.

To Chicken To Die · Jun 17, 2010, 03:26 PM // 15:26

Or a simple change can happen like toggle team that you are teamed up with someone else every match instead staying in the same team. 1 There will be no sync teams. 2 Getting 25 wins is much harder. 3 If your team isn't great why not try to win you get a new team next round. 4 Reaching 25 wins will not kick everyone but only you making it possible for others to get 25 wins aswell.

Let the sync cryers begin to flame

axe · Jun 17, 2010, 03:31 PM // 15:31

Quote:

Originally Posted by Amy Awien

If the negative effect of syncing exceeds that of an occasional long wait then the choice for the longer wait would be reasonable.

This is where you and Gill are not forward thinking, this is why such threads exist, they existed for TA, and HA before these arena's became inactive.

The players that play the arena AS INTENDED, see problems on the horizon.. we make threads to say "Just so you know, if this continues, the format will deteriorate and cease to exist"

Basically however small the negative impact of syncing is TODAY, if nothing is done about it, more people will sync, magnified by the people leaving out of frustration facing synced teams regularly ESPECIALLY in dead/inactive hours. This problem will ruin the format, why not take care of it BEFORE that happens, would have been nice for TA, would have been nice for HA.

The time of night that I play if I actually spawn a good RA team more than capable of a 25 consec. run, I already know before we hit 25 I will hit a synced team. Over the course of playing the game, I can roll a warrior and play RA for my entire alotted playtime, I used to be able to do 2-3 full runs a night, it was fun. Today, I already know that I cannot do a full run, no matter how good my team composition is, because I will hit a synced team somewhere on the run. Knowing this before I start is pretty discouraging is it not? So why bother playing if you already know that you will lose to cheaters.

So while today, during prime times of activity syncing is not out of hand, every day that this continues the number of syncers will increase, while the number of non-syncers will decrease, and the format will fail.

Borat and Lemming are high end PvP players, Anet can learn a lot from reading problems and solutions offered by either. You can continue to guess if now is a good time to address this problem, but this should have been taken care of 5 years ago, not next year AFTER the format is dead.

I wish I took the time to play HA and TA when they were at their peaks I played casually because I always knew those formats would be there and fun when I logged in, so I could do some PvE or whatever. But sadly those formats have become inactive, due to correctable problems, that were not an immediate issue when first discussed, but after leaving them alone for too long, the players lost faith and left.

Gill Halendt · Jun 17, 2010, 04:17 PM // 16:17

Quote:

Originally Posted by axe

This is where you and Gill are not forward thinking, this is why such threads exist, they existed for TA, and HA before these arena's became inactive.

Don't get me wrong... It's not that I'm not forward thinking. I do see the problem.

I'm just trying to be realist, and not to get overexcited over a suggestion that sounds great on paper, but might not work as intended when and if it ever gets implemented. That's my job, call this professional bias if you like. Things are hardly as easy as they sound in this field.

Also I see the reason why such a change is needed. But our opinion is not necessarily enough to warrant a change. Anet is running a business, and they have to come down to some compromises. If no fix is implemented, it's not simply because Anet is bad and doesn't care: they probably have some restraints and while it's undebatable fact that there's is a problem, there's little we can do to force their hands when such an issue is perceived as a minor problem by them.

That's it. I couldn't care less myself if waiting times to enter a battle were increased to fix syncing. It's just that I don't see such a fix coming anytime soon, and that's a shame.

Martin Alvito · Jun 17, 2010, 04:24 PM // 16:24

Quote:

Originally Posted by Gill Halendt

We don't know this for sure though.

As far as we know, there might be limitations to the number of games created per session. Entirely possible, since servers capacity is not infinite, so assuming that the number of games created is always N of players / 8 is potentially wrong or inaccurate.

Sure, but consider the available evidence before you. If it were the case that the server did not match all available players every time, you would observe NOP more frequently than you do now.

You only observe frequent NOPs in dead, imbalanced arenas such as AB and FA where one side tends to hold a decided advantage in returns over time. (Implication: few players join the disadvantaged side.) You observe regular NOPs in a purely dead arena like HA where few teams play, but not frequent ones.

Given player experience in RA, this is not an unreasonable assumption. Even if I'm wrong, you're looking at a possible effect on perhaps a factor of two (because it's a numerator term), where doubling the number of teams that match per iteration reduces the effect by a factor of four (denominator term).

Long story short, it isn't a dangerous assumption for a host of reasons. But I commend you for attacking the proof on valid grounds that require clarification.

Last point: as others have pointed out, this is an inexpensive coding fix. All you're looking at is switching a FIFO system to a randomized one. That's pretty elementary. Is there an introductory computer science course in a high school (much less a university) that doesn't deal with the difference between the two?

Killed u man · Jun 17, 2010, 04:35 PM // 16:35

Quote:

Originally Posted by Gill Halendt

Don't get me wrong... It's not that I'm not forward thinking. I do see the problem.

I'm just trying to be realist, and not to get overexcited over a suggestion that sounds great on paper, but might not work as intended when and if it ever gets implemented. That's my job, call this professional bias if you like. Things are hardly as easy as they sound in this field.

Also I see the reason why such a change is needed. But our opinion is not necessarily enough to warrant a change. Anet is running a business, and they have to come down to some compromises. If no fix is implemented, it's not simply because Anet is bad and doesn't care: they probably have some restraints and while it's undebatable fact that there's is a problem, there's little we can do to force their hands when such an issue is perceived as a minor problem by them.

That's it. I couldn't care less myself if waiting times to enter a battle were increased to fix syncing. It's just that I don't see such a fix coming anytime soon, and that's a shame.

But you keep talking about the waiting times "increasing", which they won't. It will just make the variance greater, and the waiting times more random.

For example:

People who always get a reset under today's system of forming groups will actually benefit, because the chance is now randomized.

People who always go in on first try will "disbenefit", because their chance is now randomized aswell.

Point being:

Overal, the waiting times do not increase. Assuming the same amount of people play, nothing will change. The only thing that will change is that you might get 3 NoP's today, (whereas you would have gotten none under the old system) but zero tomorrow. (Whereas you would have gotten 3 under the old system)

And it's even more beneficial for the people who play RA alot, because the larger amount of games you'll play, the more to the average you'll get. (So after 1,000 timers, you'll be around whatever the current value of NOP's is, or maybe even dead-on the same)

The only disbenefit from this update is that a really unlucky player might get 3 NOP's every time he wants to enter RA. And the chances for that to even happen once are redicilously low, let alone multiple times a day. (We're talking about NOP's you wouldn't have gotten during the old system. Inactivity NOP's dont count)

Martin Alvito · Jun 17, 2010, 04:40 PM // 16:40

Quote:

Originally Posted by Killed u man

But you keep talking about the waiting times "increasing", which they won't. It will just make the variance greater, and the waiting times more random.

To be precise, the wait times will increase on average. Just not by a lot, and certainly not by enough to outweigh the positives of the change if you care about glad points and Balth faction.

Quote:

Originally Posted by To Chicken To Die

Or a simple change can happen like toggle team that you are teamed up with someone else every match instead staying in the same team.

Interesting proposal, but more casual formats that kick you out after a win (JQ, FA, AB) are also impacted by syncing.

To Chicken To Die · Jun 17, 2010, 05:00 PM // 17:00

Quote:

Originally Posted by Martin Alvito

Interesting proposal, but more casual formats that kick you out after a win (JQ, FA, AB) are also impacted by syncing.

Yeah but that doesn't mean every differnt format need to change to it. See it like a solution for RA and now think of one for JQ and FA. (I don't see how it can be changed in AB since there are just a few teams that you dont need to try to sync to team up with other guild/ally team)

Martin Alvito · Jun 17, 2010, 05:26 PM // 17:26

Back in the day, we used to sync allied teams into AB early in Factions and produce 500-1X and 500-X shrine outs every match. Insanely efficient faction farming, and fun as well. Do not underestimate the power of syncing.

We're pretty much restricted to a single fix irrespective of arena, as the join mechanism probably needs to be consistent across arenas. That's what makes the Borat addition to Lemming's proposal attractive; it reduces the risks of being in the tail of the distribution in an inactive arena where being in the tail becomes a problem.

Ka Tet · Jun 17, 2010, 08:17 PM // 20:17

Is syncing endemic enough to deserve this much argument? I haven't RA'ed in years, just curious.

Gill Halendt · Jun 17, 2010, 09:05 PM // 21:05

Quote:

Originally Posted by Martin Alvito

Last point: as others have pointed out, this is an inexpensive coding fix. All you're looking at is switching a FIFO system to a randomized one. That's pretty elementary. Is there an introductory computer science course in a high school (much less a university) that doesn't deal with the difference between the two?

Easy here.

It's not "elementary" (nor inexpensive) at all... Again, don't jump to conclusions too easily. Without the source code, we can't really say, we don't even know how the teams are formed and what type of datas and algorithms the system currently uses. We're just guessing.

So, let's assume the current system is actually a FIFO implementation, and we want it to be randomized instead. The two systems work on different data structures - FIFO implies a queue, a queue implies processing items in order, in a linked list or an array, which is not the case with most randomized algorithms. So, if anything, significant portions of the code need to be rewritten, tested, debugged.

The difference might be elementary, but switching implementation in due course often is not.

Martin Alvito · Jun 17, 2010, 09:38 PM // 21:38

Quote:

Originally Posted by Gill Halendt

So, let's assume the current system is actually a FIFO implementation, and we want it to be randomized instead. The two systems work on different data structures - FIFO implies a queue, a queue implies processing items in order, in a linked list or an array, which is not the case with most randomized algorithms. So, if anything, significant portions of the code need to be rewritten, tested, debugged.

The difference might be elementary, but switching implementation in due course often is not.

Solving the problem is no more complicated than telling the computer:

1) Forget what I told you about a FIFO structure (a simple GOTO command in BASIC, ffs. Nevermind more advanced languages)
2) Randomize who gets allocated where
3) Allocate assignments accordingly

Worst case scenario: you're dealing with a hard-coded FIFO queue. If that's the case, all you have to do is assign every item in the queue a unique ID, randomly draw numbers, and pull items from the queue into a new FIFO queue based on the random draw. It's the same principle I'd use to shuffle a deck of cards. This is NOT hard, and takes minimal processing time.

You're trying to claim that something requiring a few dozen lines of code to fix is hard. Sorry, but that's the typical sort of BS that I expect to hear from tech types. If you pitch me that explanation, my response is simple: there's this thing called work you should try. It can be rewarding. Don't sit there and try to leverage expertise to convince me that simple things are hard, because I know enough about your job to know better. If I can solve the relevant problem in a week in my free time using an ancient graphing calculator and without formal training, than a trained professional can solve the problem in a day if they put their mind to it.

Amy Awien · Jun 17, 2010, 10:00 PM // 22:00

Quote:

Originally Posted by Martin Alvito

If the above is true, then if we implement Lemming's proposal, your odds of drawing a single NOP are given by 1/(8N+3.5), and the odds of drawing q NOPs in sequence are given by 1/(8N+3.5)^q.

Shouldn't this be more like 3.5/8N and (3.5/8N)^q

With N=1 and q is 4 it would then be 4%

That is assuming there are enough matches to accomodate most users.

Gill Halendt · Jun 17, 2010, 10:27 PM // 22:27

Quote:

Originally Posted by Martin Alvito

If you pitch me that explanation, my response is simple: there's this thing called work you should try. It can be rewarding.

So you assume I don't know what "this thing called work" is.

I'd rather not comment over personal attacks, expecially when they have no relevance to the discussion. Expecially when they come from a moderator, but, whatever...

Quote:

Originally Posted by Martin Alvito

If I can solve the relevant problem in a week in my free time using an ancient graphing calculator and without formal training, than a trained professional can solve the problem in a day if they put their mind to it.

Right. If they put their mind to it.

Never said it's "hard", just that it's not "elementary". Right now, they don't seem to care about this issue, so yes, a few dozen lines of code are likely enough of a deterrent.

I'll quote myself and be done with it, as you see to believe I either don't want this problem to be fixed, or think it's not possible.

Quote:

I'm just trying to be realist, and not to get overexcited over a suggestion that sounds great on paper, but might not work as intended when and if it ever gets implemented. That's my job, call this professional bias if you like. Things are hardly as easy as they sound in this field.

Also I see the reason why such a change is needed. But our opinion is not necessarily enough to warrant a change. Anet is running a business, and they have to come down to some compromises. If no fix is implemented, it's not simply because Anet is bad and doesn't care: they probably have some restraints and while it's undebatable fact that there's is a problem, there's little we can do to force their hands when such an issue is perceived as a minor problem by them.

I'm not questioning the feasability of such a change: even if I had some reservations (likely the developers have considered randomization as well way back then, but deliberatly chose to go for fair processing of the queue in exchange of some bearable syncing), I think we all agreed that Lemming's suggestion was a good one.

snaek · Jun 17, 2010, 11:12 PM // 23:12

Quote:

Originally Posted by gill halendt

I'm not questioning the feasability of such a change

then why are you posting? your arguments hold completely no value in this thread.

we are addressing a problem in this game. we are coming up with a solution to that problem. it is up to anet whether or not to what they're going to do about it; not you, not me, not anyone else but anet. theres absolutely nothing wrong with that. if you think anet is not going to do anything, then good for you, but why do you have to stop us from trying?

Gill Halendt · Jun 17, 2010, 11:31 PM // 23:31

Quote:

Originally Posted by snaek

why do you have to stop us from trying?

- Am I? I'm just saying that this is not the bowl of cherries you'd like it to be, that Lemming's suggestion is good and would solve the problem but might need some polish: some faults we've been observing in this thread are likely what kept Anet from going for full randomization before: fairness in queues is often a priority in multi-user systems for example, so it's entirely possible that Anet opted for consistent waiting times at the cost of making syncing possible. Do you really think the developers are so idiot they couldn't think of it themselves?

- Stopping you from trying what, exactly? Forums are for public discussion. Isn't this what's going on here? Aren't we discussing pro and contras of a suggested solution to a problem? Actual suggestions for the game are to be submited through the Wiki.

Martin Alvito · Jun 18, 2010, 12:34 AM // 00:34

Quote:

Originally Posted by Gill Halendt

So you assume I don't know what "this thing called work" is.

No, I'm sure you do. The line is sarcasm. The point is: if you tell me that an elementary problem requires too much effort to solve, then I'm going to respond that in this instance you are being intellectually lazy.

Quote:

Originally Posted by Gill Halendt

Never said it's "hard", just that it's not "elementary". Right now, they don't seem to care about this issue, so yes, a few dozen lines of code are likely enough of a deterrent.

And the whole point of this discussion to this point is to demonstrate that this is an absurd stance by ANet. If the problem were legitimately hard to solve, then refusing to address the issue would be acceptable. Since solving the problem would in principle take a skilled coder about a day of labor, the issue should be resolved.

Again, this problem is a straightforward extension of what you are taught in an introductory computer science course. That makes it "elementary" in my book.

Quote:

Originally Posted by Amy Awien

Shouldn't this be more like 3.5/8N and (3.5/8N)^q

No. But you're correct to point out that I have an error and you're on the right track.

The correct probability would be [3.5/(3.5+8N)]^q. That yields (roughly) up the following if N=1:

0.09 shot of double timering (which you would experience anyway)
0.028 shot of triple timering
0.008 shot of quad timering

and so forth. Basically, the error screws up the original math by roughly 0.05 in the limit (mean), but substantively increases the odds of experiencing small numbers of multiple timers. You're looking at a 1/125 shot of quad timering when N=1. The implication is that Borat's fix is very necessary for an inactive arena.

For the current RA where N is presumptively large, the math error isn't a big deal, but random assignment would eventually become an issue if we assume that activity will on average decline over time.